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Abstract 


This document describes methodologies that have been designed to 
improve and facilitate IETF document flow processing. It specifies a 
set of procedures under which a working group chair or secretary 
serves as the primary Document Shepherd for a document that has been 
submitted to the IESG for publication. Before this, the Area 
Director responsible for the working group has traditionally filled 
the shepherding role. 


Levkowetz, et al. Informational [Page 1] 


RFC 4858 Document Shepherding to Publication 


Table of Contents 


N He 


w w 


rFoOAHTA USDA 


0. 


Introduction 
Terminology A 
Process Description 


«1. Document Shepherd Write- “Up 
-2. Document Shepherding during AD Evaluacion 
.3. Document Shepherding during IESG Evaluation 


Shepherding the Document’s IANA Actions 

Document Shepherding after IESG Approval 

When Not to Use the Document Shepherding Process 
Security Considerations 

TANA Considerations 

Acknowledgments 

References 


10.1. Normative heferencës 


10.2. Informative References 
Appendix A. Example Document Announcement Write- Ups 


A.1. Example Document Announcement Write-Up for 
draft-ietf-avt-rtp-midi-format 
A.2. Example Document Announcement Write-Up for 
draft-ietf-imss-ip-over-fibre-channel 
Levkowetz, et al. Informational 


May 2007 


[Page 2] 


RFC 4858 Document Shepherding to Publication May 2007 


Le 


Introduction 


Early in 2004, the IESG undertook several experiments aimed at 
evaluating whether any of the proposed changes to the IETF document 
flow process would yield qualitative improvements in document 
throughput and quality. One such experiment, referred to as the 
"PROTO process" or "PROTO" (because it was created by the "PROcess 
and TOols" or PROTO [PROTO] team), is a set of methodologies designed 
to involve working group chairs or secretaries more directly in their 
documents’ approval life cycle. In particular, the PROTO team 
focused on improvements to the part of a document’s life cycle that 
occurs after the working group and document editor have forwarded it 
to the IESG for publication. 


By the end of 2004, the IESG had evaluated the utility of the PROTO 
methodologies based on data obtained through several pilot projects 
that had run throughout the year, and subsequently decided to adopt 
the PROTO process for all documents and working groups. This 
document describes this process. 


The methodologies developed and piloted by the PROTO team focus on 
the working group chair or secretary as the primary Document 
Shepherd. The primary objective of this document shepherding process 
is to improve document-processing throughput and document quality by 
enabling a partnership between the Responsible Area Director and the 
Document Shepherd. In particular, this partnership has the explicit 
goal of enfranchising the Document Shepherd while at the same time 
offloading a specific part of the follow-up work that has 
traditionally been responsibility of the Responsible Area Director. 
The Responsible Area Director has tens or many tens of documents to 
follow, while the Document Shepherd has only a few at a time. 

Flowing the responsibility to the working group level can ensure more 
attention and more timely response. 


Consequently, the document shepherding process includes follow-up 
work during all document-processing stages after Working Group Last 
Call, i.e., during AD Evaluation of a document, during IESG 
Evaluation, and during post-approval processing by IANA and the RFC 
Editor. In these stages, it is the responsibility of the Document 
Shepherd to track and follow up on feedback received on a document 
from all relevant parties. 


The Document Shepherd is usually a chair of the working group that 
has produced the document. In consultation with the Responsible Area 
Director, the chairs may instead decide to appoint the working group 
secretary as the responsible Document Shepherd. 
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De 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


Process Description 
The document shepherding process consists of the following tasks: 


o Providing the Document Shepherd Write-Up accompanying a document 
that is forwarded to the IESG when publication is requested, as 
described in Section 3.1. 


o During AD Evaluation of the document by the Responsible Area 
Director, managing the discussion between the editors, the working 
group, and the Responsible Area Director, as described in 
Section 3.2. 


o During an IETF Last Call, if performed for the shepherded 
document, following up on community feedback and review comments. 


o During IESG Evaluation, following up on all IESG feedback 
("DISCUSS" and "COMMENT" items) related to the shepherded 
document, as described in Section 3.3. 


o Following up on IANA and RFC Editor requests as described in 
Section 4 and Section 5. 


The shepherd must keep the document moving forward, communicating 
about it with parties who review and comment on it. The shepherd 
must obtain the working group’s consensus for any substantive 
proposed changes. The shepherd is the leader for the document and 
for the working group, and maintains a critical and technical 
perspective. In summary, the Document Shepherd continues to care for 
a shepherded document during its post-WG lifetime just as he or she 
has done while responsible for the document in the working group. 


Before any document shepherding takes place, a single Document 
Shepherd MUST be identified for a document (he or she will be named 
in the Document Shepherd Write-Up). Frequently, the chairs and the 
Responsible Area Director will decide that the working group will 
adopt the PROTO process for all their future documents. After that 
decision, the chairs, in consultation with the Responsible Area 
Director, decide on who should act as Document Shepherd for any given 
document. This is typically and by default one of the chairs of the 
working group. In consultation with the Responsible Area Director, 
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the chairs MAY also decide to appoint the working group secretary as 
Document Shepherd for a given document. The Document Shepherd SHOULD 
NOT be an editor of the shepherded document. 


It is intended that the Document Shepherd role be filled by one 
person during the entire shepherding process. However, situations 
may occur when the Document Shepherd role may be reassigned to 
different persons during the lifetime of a document. It is up to the 
chairs and Responsible Area Director to identify situations when this 
may become necessary, and then consult to appoint a new Document 
Shepherd. 


It is important to note that the document shepherding process only 
applies to documents that are the product of a working group. It 
does not apply to documents that originate elsewhere. Additionally, 
Section 6 discusses other instances in which the document shepherding 
process does not apply. 


3.1. Document Shepherd Write-Up 


When a working group decides that a document is ready for submission 
to the IESG for publication, it is the task of the Document Shepherd 
to complete a "Document Shepherd Write-Up" for the document. 


There are two parts to this task. First, the Document Shepherd 
answers questions (1.a) to (1.3) below to give the Responsible Area 
Director insight into the working group process that applied to this 
document. Note that while these questions may appear redundant in 
some cases, they are written to elicit information that the 
Responsible Area Director must be aware of (to this end, pointers to 
relevant entries in the WG archive are helpful). The goal here is to 
inform the Responsible Area Director about any issues that may have 
come up in IETF meetings, on the mailing list, or in private 
communication that they should be aware of prior to IESG Evaluation 
of the shepherded document. Any significant issues mentioned in the 
questionnaire will probably lead to a follow-up discussion with the 
Responsible Area Director. 


The second part of the task is to prepare the "Document Announcement 
Write-Up" that is input both to the ballot for the IESG telechat and 
to the eventual IETF-wide announcement message. Item number (1.k) 
describes the elements of the Document Announcement Write-Up. 


Some examples of Document Announcement Write-Ups are included in 
Appendix A, and there are many more examples with subject lines such 
as "Protocol Action" and "Document Action" in the IETF-announce 
mailing list archive. 
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The initial template for the Document Shepherd Write-Up is included 


below, 


but changes are expected over time. The latest version of 


this template is available from the IESG section of the IETF web 


site. 


(1.a) 


(1.d) 


(1.e) 


(1.£) 


Levkowetz, 


Who is the Document Shepherd for this document? Has the 
Document Shepherd personally reviewed this version of the 
document and, in particular, does he or she believe this 
version is ready for forwarding to the IESG for publication? 


Has the document had adequate review both from key WG members 
and from key non-WG members? Does the Document Shepherd have 
any concerns about the depth or breadth of the reviews that 
have been performed? 


Does the Document Shepherd have concerns that the document 
needs more review from a particular or broader perspective, 
e.g., security, operational complexity, someone familiar with 
AAA, internationalization, or XML? 


Does the Document Shepherd have any specific concerns or 
issues with this document that the Responsible Area Director 
and/or the IESG should be aware of? For example, perhaps he 
or she is uncomfortable with certain parts of the document, or 
has concerns whether there really is a need for it. In any 
event, if the WG has discussed those issues and has indicated 
that it still wishes to advance the document, detail those 
concerns here. Has an IPR disclosure related to this document 
been filed? If so, please include a reference to the 
disclosure and summarize the WG discussion and conclusion on 
this issue. 


How solid is the WG consensus behind this document? Does it 
represent the strong concurrence of a few individuals, with 
others being silent, or does the WG as a whole understand and 
agree with it? 


Has anyone threatened an appeal or otherwise indicated extreme 
discontent? If so, please summarize the areas of conflict in 
separate email messages to the Responsible Area Director. (It 
should be in a separate email because this questionnaire is 
entered into the ID Tracker.) 


Has the Document Shepherd personally verified that the 


document satisfies all ID nits? (See 
http://www.ietf.org/ID-Checklist.html and 
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are 


not enough; this check needs to be thorough. Has the document 
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(1.h) 


(1.i) 


(1.k) 
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met all formal review criteria it needs to, such as the MIB 
Doctor, media type, and URI type reviews? If the document 
does not already indicate its intended status at the top of 
the first page, please indicate the intended status here. 


Has the document split its references into normative and 
informative? Are there normative references to documents that 
are not ready for advancement or are otherwise in an unclear 
state? If such normative references exist, what is the 
strategy for their completion? Are there normative references 
that are downward references, as described in [RFC3967]? If 
so, list these downward references to support the Area 
Director in the Last Call procedure for them [RFC3967]. 


Has the Document Shepherd verified that the document’s IANA 
Considerations section exists and is consistent with the body 
of the document? If the document specifies protocol 
extensions, are reservations requested in appropriate IANA 
registries? Are the IANA registries clearly identified? If 
the document creates a new registry, does it define the 
proposed initial contents of the registry and an allocation 
procedure for future registrations? Does it suggest a 
reasonable name for the new registry? See [RFC2434]. If the 
document describes an Expert Review process, has the Document 
Shepherd conferred with the Responsible Area Director so that 
the IESG can appoint the needed Expert during IESG Evaluation? 


Has the Document Shepherd verified that sections of the 
document that are written in a formal language, such as XML 
code, BNF rules, MIB definitions, etc., validate correctly in 
an automated checker? 


The IESG approval announcement includes a Document 
Announcement Write-Up. Please provide such a Document 
Announcement Write-Up. Recent examples can be found in the 
"Action" announcements for approved documents. The approval 
announcement contains the following sections: 


Technical Summary 
Relevant content can frequently be found in the abstract 
and/or introduction of the document. If not, this may be 
an indication that there are deficiencies in the abstract 
or introduction. 
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Working Group Summary 
Was there anything in the WG process that is worth noting? 
For example, was there controversy about particular points 
or were there decisions where the consensus was 
particularly rough? 


Document Quality 
Are there existing implementations of the protocol? Have a 
significant number of vendors indicated their plan to 
implement the specification? Are there any reviewers that 
merit special mention as having done a thorough review, 
e.g., one that resulted in important changes or a 
conclusion that the document had no substantive issues? If 
there was a MIB Doctor, Media Type, or other Expert Review, 
what was its course (briefly)? In the case of a Media Type 
Review, on what date was the request posted? 


Personnel 
Who is the Document Shepherd for this document? Who is the 
Responsible Area Director? If the document requires IANA 
experts(s), insert ‘The IANA Expert (s) for the registries 
in this document are <TO BE ADDED BY THE AD>.’ 


The Document Shepherd MUST send the Document Shepherd Write-Up to the 
Responsible Area Director and iesg-secretary@ietf.org together with 
the request to publish the document. The Document Shepherd SHOULD 
also send the entire Document Shepherd Write-Up to the working group 
mailing list. If the Document Shepherd feels that information which 
may prove to be sensitive, may lead to possible appeals, or is 
personal needs to be written up, it SHOULD be sent in direct email to 
the Responsible Area Director, because the Document Shepherd Write-Up 
is published openly in the ID Tracker. Question (1.f) of the 
Write-Up covers any material of this nature and specifies this more 
confidential handling. 


The Document Shepherd Write-Up is entered into the ID Tracker 
[IDTRACKER] as a "Comment". The name and email address of the 
Document Shepherd are entered into the ID Tracker, currently as a 
"Brief Note" (this may change in the future). The email address of 
the Document Shepherd MUST also be added to the "State or Version 
Change Notice To" field (typically the email addresses of all working 
group chairs, authors, and the secretary will be added). 


Entering the name and email of the Document Shepherd into the ID 
Tracker is REQUIRED to ensure that he or she will be copied on the 
email exchange between the editors, chairs, the IESG, the IESG 
secretariat, IANA, and the RFC Editor during the review and approval 
process. There are still manual steps required for these parties to 
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ensure that they include the Document Shepherd, but it is hoped that 
in the future, automated tools will ensure that Document Shepherds 
(and others) receive necessary communications. 


The contact information for the Document Shepherd is also important 
for the Gen-ART team [GEN-ART], area directorates, and other review 
teams, so they can know to whom to address reviews, in addition to 
the Responsible Area Director. 


3.2. Document Shepherding during AD Evaluation 


The steps for document shepherding during AD Evaluation are as 
follows: 


(2.a) The Responsible Area Director reads, evaluates, and comments 
on the document, as is the case when not using the document 
shepherding process. If the Responsible Area Director 
determines that the document is ready for IESG Evaluation, he 
or she indicates this to the Document Shepherd and the 
document shepherding process continues as described in 
Section 3.3. 


(2.b) If the Responsible Area Director has identified issues with a 
document that must be addressed before IESG Evaluation can 
commence, he or she sends a full evaluation to the Document 
Shepherd and SHOULD also enter the review into the ID Tracker. 


(2.c) The Document Shepherd reads the AD Evaluation comments, making 
very certain that all comments are understood, so that it is 
possible to follow up on them with the editors and working 
group. If there is some uncertainty as to what is requested, 
this SHOULD be resolved with the Responsible Area Director. 


(2.d) The Document Shepherd sends the AD Evaluation comments to the 
editors and to the working group mailing list, in order to 
have a permanent record of the comments. It is RECOMMENDED 
that the Document Shepherd solicit from the editors an 
estimate on when the required changes will be completed and a 
revised document can be expected. Working groups that use 
issue tracking SHOULD also record the issues (and eventually 
their resolution) in their issue tracker. 


(2.e) During the production of a revised document that addresses the 
AD Evaluation comments, it is RECOMMENDED that the editors 
keep a list showing how each comment was addressed and what 
the revised text is. It is RECOMMENDED that this list be 
forwarded to the Responsible Area Director together with the 
revised document. 
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In the event that the editors or working group disagrees with 
a comment raised by the Responsible Area Director or has 
previously considered and dismissed the issue, the Document 
Shepherd MUST resolve the issue with the Responsible Area 
Director before a revised document can be submitted. 


The Document Shepherd iterates with the editors (and working 
group, if required) until all outstanding issues have been 
resolved and a revised document is available. At this point, 
the Document Shepherd notifies the Responsible Area Director 
and provides him or her with the revised document, the summary 
of issues, and the resulting text changes. 


The Responsible Area Director verifies that the issues he or 
she found during AD Evaluation are resolved in the revised 
version of the document by starting the process described in 
this section at step (2.a). 


If the document underwent an IETF Last Call and the AD 
concludes that significant issues were raised during the Last 
Call, then steps (2.b) through (2.h) need to be applied 
addressing the Last Call issues. This requires the 
Responsible Area Director to present to the Document Shepherd 
those Last Call issues raised only to the IESG. 


3.3. Document Shepherding during IESG Evaluation 


During 


manner 


TESG Evaluation of a document, ADs can bring forward two kinds 


of remarks about a document: DISCUSS items and COMMENT items. A 
DISCUSS blocks a document’s approval process until it has been 
resolved; a COMMENT does not. This section details the steps that a 
Document Shepherd takes to resolve any DISCUSS and COMMENT items 
brought forward against a shepherded document during IESG Evaluation. 


Note that DISCUSS and COMMENT items are occasionally written ina 


that makes their intent unclear. In these cases, the Document 


Shepherd SHOULD start a discussion with the ADs who brought the items 
up to clarify their intent, keeping the Responsible Area Director 
informed. If this fails to clarify the intent, the Responsible Area 
Director may need to work towards a clarification inside the IESG. 


(3.a) 


Levkowetz, 


Leading up to the IESG conference call, the Document Shepherd 
may see emails about the document from directorate reviewers 
on behalf of one or more ADs and also emailed copies of 
DISCUSS and COMMENT items entered into the ID Tracker. The 
Document Shepherd SHOULD immediately begin to work on 
resolving DISCUSS and COMMENT items with the ADs who have 
raised them, keeping the Responsible Area Director copied on 
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the email exchange, so that he or she is able to support the 
activity during the conference call. When dealing with 
directorate reviews, the Document Shepherd MUST involve the 
ADs to whom these directorates report to ensure that these ADs 
consider the review comments that need resolving. 


Immediately following the conference call, when the document 
changes state from the "IESG Evaluation" state to one of the 
states requiring Document Shepherd action, e.g., "IESG 
Evaluation: Revised ID Needed" or "IESG Evaluation: AD 
Followup", the Document Shepherd will receive email. A state 
of "AD Followup" typically signifies the Responsible Area 
Director’s hope that a resolution may be possible through a 
continued discussion or (more usually) through a small set of 
changes as "Notes to the RFC Editor". 


Note that there may be very exceptional cases when DISCUSS 


items are registered after an IESG conference call. In these 
cases, the AD who has raised the DISCUSS MUST notify the 
Document Shepherd about it. (The notification facility in the 


ID Tracker is very convenient for this purpose and also for 
the cases where the DISCUSS and COMMENT items are updated 
after they are partially resolved.) 


The Document Shepherd then queries the ID Tracker to collect 
the remaining DISCUSS and COMMENT items raised against the 
document. The Document Shepherd analyzes these items and 
initializes contact with the ADs who have placed them. The 
Responsible Area Director MUST be copied on all correspondence 
related to active DISCUSS or COMMENT items. This does not 
place the Responsible Area Director in the critical path 
towards a resolution, but should keep him or her informed 
about the state of the discussion. 


HESSE + Comments tosses + Comments isen + 
collected LIN understood 


Comments not fully understood 
(Further AD/Document Shepherd 
discussion required) 


+ ——————— 


+-—-—- 


The Document Shepherd then coordinates the resolution of 
DISCUSS and COMMENT items and builds a consistent 
interpretation of the comments. This step is similar to much 
of the process described in Section 3.2. 
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+------- + Consistent Joos + 
/\\ interpretation | 
| | Further AD/Document Shepherd 
| discussion required 


The Document Shepherd then communicates the DISCUSS and 
COMMENT items to the document editors and the working group, 
alerting them of any changes to the document that have 
accumulated during IESG processing, such as "Notes to the RFC 
Editor". If any changes will be substantive, the Document 
Shepherd, in consultation with the Responsible Area Director, 
as during other stages, MUST confirm working group consensus 
or sometimes even IETF consensus. 


After the editors resolve the DISCUSS and COMMENT items, the 
Document Shepherd reviews the resulting new version of the 
document, which will be a revised document, a set of "Notes to 
the RFC Editor", or both, using his or her technical expertise 
to ensure that all raised DISCUSS and COMMENT issues have been 
resolved. 


Note that the Document Shepherd MAY also suggest resolutions 
to DISCUSS and COMMENT items, enter them into an issue 
tracker, or perform other steps to streamline the resolution 
of the evaluation comments. It is very important to resolve 
the comments in a timely way, while the discussion is current 
for everyone involved. 


When the Document Shepherd is satisfied that the revised 
document addresses the evaluation comments, he or she 
communicates the resolution to the Responsible Area Director 
and the ADs that had raised the DISCUSS and COMMENT items. 


Each AD who had raised a DISCUSS checks whether the 
communicated resolution addresses his or her items. If it 
does, the AD will clear the DISCUSS. If it does not, the AD 
notifies the Document Shepherd and adds information to the ID 
Tracker explaining why the DISCUSS was not resolved. The 
Document Shepherd informs the working group accordingly. 
(COMMENT items need not be checked and cleared, because they 
do not block the document, but ADs are encouraged to do so.) 


If a DISCUSS was not resolved to the satisfaction of the AD 
that has raised it or the Responsible Area Director, two 
possibilities exist: 
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4. 


(a) The process returns to step (3.d), or 


(b) If no progress can be made on the resolution of the 
DISCUSS with the AD who has raised it, despite repeated 
clarifications and discussions, the Responsible Area 
Director should take over continued shepherding of the 
document. Such a situation may be indicative of larger 
issues that the PROTO process was not designed to handle. 


Once the process above has cleared all DISCUSS items, document 
shepherding continues with step (3.1). 


(3.i) The Responsible Area Director moves the document to the 
"Approved - Announcement to be sent" state in the ID Tracker. 
If he or she deems the changes to the revised document 
significant, there may be a new WG Last Call, or possibly a 
new IETF Last Call. The document goes through a new full IESG 
Evaluation process if there is a new IETF Last Call. 


Shepherding the Document’s IANA Actions 


IETF working group documents often include considerations requiring 
actions by the IANA, such as creating a new registry or adding 
information to an existing registry, perhaps after consulting an 
IESG-appointed Expert. Sometimes the Document Shepherd must keep 
track of certain IANA actions to be completed by the IESG, such as 
ratifying the appointment of a designated Expert called for in the 
IANA Considerations. IANA-related processing may also include a 
specified type of Expert review, such as review of proposed MIME 
media types on the designated ietf-types mailing list. 


The IANA reviews IETF documents and requests responses at any or all 
of the following times: in response to IETF Last Call, during the 
IESG Evaluation review of the document, and at the time when the IANA 
performs actions in its web-based registry for the document, usually 
but not always after IESG approval of the document. More details of 
the IANA process and IETF interaction are found in [RFC2434]. 


At the time of this publication, RFC 2434 is under revision 
[RFC2434bis], and the updates are and will be of value to the 
Document Shepherd. Note that the Document Shepherd MUST determine 
(by individual review and consultation with others) what is the most 
recent and the most applicable IANA information and guidance for his 
or her document, be it the overall guidance, or external documents in 
his or her area, or in other areas. An example of an external 
document is [RFC4020]. 
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Whenever an IANA request comes, during whatever phase of the 
shepherding process, the requester from IANA MUST ensure that the 
Document Shepherd and the Responsible Area Director both receive the 
request. The Document Shepherd is responsible for responding as 
rapidly as possible. He or she should discuss requests that 
introduce any possible concerns with the working group. The Document 
Shepherd and the Responsible Area Director may decide in consultation 
that an IANA request leads to a change that needs additional review 
or approval. 


In general, the Document Shepherd ensures that the IANA process 
completes, checks that the registry is correct and that the IANA 
Matrix (http://www.iana.org/numbers.html) is complete and consistent, 
and troubleshoots when all is not well. At the end of IANA 
processing, the Document Shepherd should be sure that the RFC Editor 
has acknowledged IANA conclusion, i.e., that the handoff has been 
made. 


In summary, the task of shepherding the IANA actions is often 
overlooked, but is as important to coordinate and manage as all the 
other document reviews the Document Shepherd has managed. As with 
those, the Document Shepherd contributes greatly to quality and 
timeliness of the document by effective and responsive shepherding of 
the IANA requests. 


5. Document Shepherding after IESG Approval 


After the IESG Evaluation and resolution described in Section 3.3, 
the IESG approves the document, and the Responsible Area Director 
uses the ID Tracker to ask for any final changes to the Document 
Announcement Write-Up and for it to be issued. The Document Shepherd 
may have some edits for the Responsible Area Director, such as minor 
"Notes to the RFC Editor", and this is the time to consult and 
provide them. 


The IESG approval announcement goes to the general community and to 
the RFC Editor, and now the Document Shepherd (identified in the 
Announcement Write-Up) continues to shepherd the document through its 
technical publication. The RFC Editor currently makes a number of 
types of requests to the authors, Document Shepherd and Responsible 
Area Director. The Document Shepherd SHOULD lead in responding to 
the RFC Editor and shepherd the document during the post-approval 
period to its publication. 


The RFC Editor request types include: editorial queries about 
dangling or missing informative and normative citations (good 
shepherding should try to catch these earlier, but they happen); 
requests for the document source (e.g., XML or nroff); occasional 
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technical comments; and copy-edits for review and close scrutiny by 
the authors (AUTH48). For the latter, the Document Shepherd SHOULD 
lead in checking that copy-edits have in no case affected a consensus 
wording of the working group that prepared the document, and SHOULD 
bring speed to this checking by multiple coauthors. The Document 
Shepherd also consults with the Responsible Area Director on 
reviewing proposed post-approval changes to the document by any 
author. These may require Area Director approval, and they often 
need to be presented to the working group for consent if not a full 
consensus procedure. 


As in other phases of document shepherding, the Document Shepherd 
provides attentiveness and timeliness by serving as the informed 
representative of the document and helping its advancement and its 
integrity. 


6. When Not to Use the Document Shepherding Process 


As mentioned in Section 3, the Document Shepherd SHOULD NOT be an 
editor of the shepherded document. If this cannot be avoided by 
making another working group chair or secretary the Document 
Shepherd, the document shepherding process SHOULD NOT be used. There 
are several other cases in which the document shepherding process 
SHOULD NOT be used. These include: 


1. Cases where the Document Shepherd is the primary author or editor 
of a large percentage of the documents produced by the working 
group. 

2. Cases where the Responsible Area Director expects communication 


difficulties with the Document Shepherd (either due to 
experience, strong views stated by the Document Shepherd, or 
other issues). 


3. Cases where the working group itself is either very old, losing 
energy, or winding down (i.e., cases where it would not be 
productive to initiate new processes or procedures). 


Finally, note that other cases exist in which using the document 
shepherding process may not be productive. The final determination 
as to whether or not to use the document shepherding process is left 
to the Responsible Area Director. If the document shepherding 
process is not used, the Responsible Area Director acts as Document 
Shepherd, per the existing procedures of shepherding by Area 
Directors. 
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7. 


Security Considerations 


This document specifies a change to IETF document-processing 
procedures. As such, it neither raises nor considers protocol- 
specific security issues. 


IANA Considerations 


This document creates no new requirements on IANA namespaces or other 
IANA requirements. 
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Appendix A. Example Document Announcement Write-Ups 


This appendix includes two examples of Document Announcement Write- 
Ups. Many more examples with Subject lines such as "Protocol Action" 
and "Document Action" can be found in the IETF-announce mailing list 
archive. 


A.1. Example Document Announcement Write-Up for 
draft-ietf-avt-rtp-midi-format 


Technical Summary 


These documents define the RTP Payload format for MIDI (Musical 
Instrument Digital Interface), and additional guidelines on 
implementation specifically concerning the timing of reception and 
transmission for best performance in different applications. MIDI 
is a real-time media, which however is brittle to losses and 
errors. Therefore the RTP payload format defines recovery 
journals as a way of avoiding persistent audible errors, and 
discusses congestion control handling for these journals. 


The RIP payload for MIDI encodes the broad range of MIDI commands. 
The format is suitable for interactive applications (such as 
network musical performance) and content-delivery (such as file 
streaming). 

Working Group Summary 
There is consensus in the WG to publish these documents. 

Document Quality 
This RTP Payload format has been implemented during the 


development of the specification and successfully tested over an 
IP network between two remote sites, thus showing that the 


technical solution is successfully working. It has been reviewed 
by the MIDI Manufacturers Association and their comments have been 
addressed. 

Personnel 


Magnus Westerlund and Colin Perkins jointly shepherded this 
document. Allison Mankin reviewed the document for the IESG, 
including a careful review with the editor of the media types, in 
parallel with ietf-types list review requested on 2006-01-08, 
which raised no issues. 
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A.2. Example Document Announcement Write-Up for 
draft-ietf-imss-ip-over-fibre-channel 


Technical Summary 


This document specifies the encapsulation of IPv6, IPv4 and ARP 
packets over Fibre Channel. This document also specifies the 
methods for forming IPv6 link-local addresses and statelessly 
autoconfigured IPv6 addresses on Fibre Channel networks, and a 
mechanism to perform IPv4 address resolution over Fibre Channel 
networks. This document (when published as RFC) obsoletes RFC2625 
and RFC3831. 


Working Group Summary 


This document has been reviewed by Fibre Channel experts in 
Technical Committee T11 (Fibre Channel standards organization) in 
addition to members of the IMSS WG. There is solid support for 
this document both in the WG and from T11. 


Document Quality 


This document replaces and consolidates two separate RFCs on IPv4 
over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 
3831). Most of its technical content is unchanged from those 
RFCs. The technical changes that have been made are primarily 
based on implementation experience. 


Personnel 
The protocol has been reviewed for the IESG by David L. Black (WG 
chair). Bert Wijnen has reviewed this document for the IESG. In 


addition, Brian Haberman has done a review for the INT Area as 
requested by WG-chair (David Black) via Margaret Wasserman. 
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